\section{Project Plan}

Our weekly meetings with our TA Hemanth helped us greatly in our
planning process.  At the early stages, while we were still figuring
out what DiGr was really about, we had weekly meetings on Monday
nights to discuss a plan of attack for the rest of the project. We set
several deadlines, some of which we were able to meet and some of
which had to be pushed back due to heavy courseloads and the loss of a
teammate.  Around the midway point of the semester we started to
diverge in the work we were doing: Ari and Bryan focused on the
frontend while Dennis began the process of writing an airtight
backend. At this point, tasks were atomic enough that the team could
split up and each person could implement his part of the design
contract. As the semester progressed, meetings became more frequent
but less formal in how often they would occur or how long they would
last. As the semester wound down and reading week began, the team met
almost every night to work on the project.

\subsection{Project Timeline}

Our ideal timeline is outlined below. As is common, there was more of
a crunch towards the end of the project than we expected, as unknown
unknowns came up.

\begin{itemize}
\item 11/14: Begin scanner/parser/ast development in parallel.
\item 11/22: Begin first stage of interpreter development (namespace
  issues, scoping).
\item 12/1: First tests ran, at the syntactic/semantic level.
\item 12/3: 90\% completion of the core of the DiGr front-end.
\item 12/5: Begin development of C++ AST + compiler in parallel, while
  also working on the C++ backend and translator. Front-end is stable
  but occasional changes in the language are written in.
\item 12/10: 95\% completion on C++ backend and compiler.
\item 12/11: 95\% completion on translator. First complete pipeline
  from DiGr code to executable output.
\item 12/15: First run of entire test suite. Many errors.
\item 12/15-12/22: Finishing implementation, test battery, writing
  documentation.
\end{itemize}

\subsection{Style Guide}

The focus of our style plan was to break up the OCaml code into its
logical pieces with a tabbing and newline scheme. All statements under
the let statement that defines a function is given an additional level
of tabbing. In a match statement, all the values are indented and the
match comparisons form a single column.  If the result section of each
match spills past the readable length of our text editor, it was moved
to the next line and an additional level of tabbing was added.

{\tt If} statements were lined up in a single column as follows:


\begin{verbatim}
                if condition
                then statement
                else statement
\end{verbatim}

Any nested statements within these clauses is indented. When a single
line of code gets long, we break it up over multiple indented lines,
usually by the various arguments being passed to a method.

In the compiler and translator, our naming scheme for bound functions
was to make explicit what the inputs and outputs are. For example,
{\tt cexpr\_from\_expr} took a single DiGr AST {\tt expr} as an
argument and returned a single C++ AST {\tt cexpr}. This saved some
significant time looking up the formatting of various functions when
dealing with crawling the typed abstract syntax trees.

\subsection{Team Member Roles and Responsibilities}

Due partially to the small size of our team, and partially to a need
to develop quickly, all three team members made at least nominal
changes to every part of the compiler. With that in mind, the {\em
  main} duties of each team member were as follows:

\begin{itemize}
\item {\bf Bryan} (Team Leader): scanner / parser front-end, type checking /
static semantic checking in the interpreter, C++ and DiGr AST
development, team organization, language white paper 

\item {\bf Dennis}: initial symbol table / static semantic checking in the
interpreter, translation involving DiGr objects and opt/crawl/rules,
compilation work, C++ backend, documentation structure.

\item {\bf Ari}: scanner / parser front-end, translation work involving
connection contexts and arrays, some compilation work, testing suite
and test paradigm writeup.
\end{itemize}

The initial language design, as well as the language reference manual,
was a team responsibility.


\subsection{Software Development Environment} 

% tools and language

The DiGr compiler itself is written in OCaml, and the scanner and
parser use the OCaml lex and yacc extensions. The backend is written
in C++ with the use of a handful of specific standard libraries
(vector, algorithm, iostream, etc.). The documentation is written in
\LaTeX, {\tt make} was used for build management, a {\tt subversion}
repository hosted by Google Code was used for version control, and
some flowcharts in the documentation were made with GraphViz {\tt
  dot}. {\tt bash} shell scripting was used to run out test suite, and
a {\tt python} script formatted the commit logs and actual code base
for inclusion into the final report.

The development tools used varied among team members. Dennis used
plain old {\tt emacs} and the command line. Ari used {\tt gedit} with
Ocaml syntax highlighting and command line. Bryan used  {\tt gedit} as well
with cygwin to compile all Ocaml code.




\subsection{Project Log}

{\footnotesize \tt
\input{svn_log}
}
